home *** CD-ROM | disk | FTP | other *** search
-
-
- Network Working Group W A Simpson
- Internet Draft Daydreamer
- expires in six months October 1993
-
-
- PPP over ISDN
- draft-ietf-pppext-isdn-03.txt
-
-
-
- Status of this Memo
-
- This document is the product of the Point-to-Point Protocol Working
- Group of the Internet Engineering Task Force (IETF). Comments should
- be submitted to the ietf-ppp@ucdavis.edu mailing list.
-
- Distribution of this memo is unlimited.
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. Note that other groups may also distribute
- working documents as Internet Drafts.
-
- Internet Drafts are draft documents valid for a maximum of six
- months. Internet Drafts may be updated, replaced, or obsoleted by
- other documents at any time. It is not appropriate to use Internet
- Drafts as reference material or to cite them other than as a
- ``working draft'' or ``work in progress.''
-
- Please check the 1id-abstracts.txt listing contained in the
- internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
- nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
- current status of any Internet Draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page i]
- DRAFT PPP over ISDN October 1993
-
-
- Abstract
-
- The Point-to-Point Protocol (PPP) [1] provides a standard method for
- transporting multi-protocol datagrams over point-to-point links.
-
- This document describes the use of PPP over Integrated Services
- Digital Network (ISDN) switched circuits.
-
-
- Applicability
-
- This specification is intended for those implementations which desire
- to use the PPP encapsulation over ISDN point-to-point links. PPP is
- not designed for multi-point or multi-access environments.
-
- "It is clear that there is never likely to be a single, monolithic,
- worldwide ISDN." [7] The goal of this document is to describe a few
- common implementations, chosen from the current wide variety of
- alternatives, in an effort to promote interoperability.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page ii]
- DRAFT PPP over ISDN October 1993
-
-
- 1. Introduction
-
- PPP was designed as a standard method of communicating over point-
- to-point links. Initial deployment has been over short local lines,
- leased lines, and plain-old-telephone-service (POTS) using modems.
- As new packet services and higher speed lines are introduced, PPP is
- easily deployed in these environments as well.
-
- This specification is primarily concerned with the use of the PPP
- encapsulation over ISDN links. Since the ISDN B-channel is by
- definition a point-to-point circuit, PPP is well suited to use over
- these links.
-
- The ISDN Primary Rate Interface (PRI) may support many concurrent B-
- channel links. The PPP LCP and NCP mechanisms are particularly
- useful in this situation in reducing or eliminating hand
- configuration, and facilitating ease of communication between diverse
- implementations.
-
- The ISDN D-channel can also be used for sending PPP packets when
- suitably framed, but is limited in bandwidth and often restricts
- communication links to a local switch.
-
- The terminology of ISDN can be confusing. Here is a simple graphical
- representation of the points used in subsequent descriptions:
-
- +-------+ +-------+ +-------+
- R | | S | | T | | U
- +---+ TA +--+--+ NT2 +--+--+ NT1 +---+
- | | | | | |
- +-------+ +-------+ +-------+
-
- These elements are frequently combined into a single device.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 1]
- DRAFT PPP over ISDN October 1993
-
-
- 2. Physical Layer Requirements
-
- PPP treats ISDN channels as bit or octet oriented synchronous links.
- These links MUST be full-duplex, but MAY be either dedicated or
- circuit-switched.
-
- Interface Format
-
- PPP presents an octet interface to the physical layer. There is
- no provision for sub-octets to be supplied or accepted.
-
- The octet stream is applied primarily at the R or T reference
- points.
-
- Transmission Rate
-
- PPP does not impose any restrictions regarding transmission rate,
- other than that of the particular ISDN channel interface.
-
- Control Signals
-
- PPP does not require the use of control signals. When available,
- using such signals can allow greater functionality and
- performance. Implications are discussed in [2].
-
- Control signals MAY be required by some of the framing techniques
- described, and is outside the scope of this specification.
-
- Encoding
-
- The definition of various encodings and scrambling is the
- responsibility of the DTE/DCE equipment in use, and is outside the
- scope of this specification.
-
- While PPP will operate without regard to the underlying
- representation of the bit stream, lack of standards for
- transmission will hinder interoperability as surely as lack of
- data link standards. The D-channel LAPD interface requires NRZ
- encoding at the T reference point. Therefore, as a default, it is
- recommended that NRZ be used over the B-channel interface at the T
- reference point. This will allow frames to be easily exchanged
- between the B and D channels.
-
- When configuration of the encoding is allowed, NRZI is recommended
- as an alternative in order to ensure a minimum ones density where
- required over the clear B-channel, with caveats regarding FCS [2].
-
- Historically, some implementations have used Inverted NRZ (merely
-
-
-
- Simpson expires in six months [Page 2]
- DRAFT PPP over ISDN October 1993
-
-
- switching the sense of mark and space), in order to ensure a
- minimum ones density with bit-synchronous HDLC. The use of
- Inverted NRZ is deprecated.
-
- Automatic Detection
-
- Implementations which desire to interoperate with multiple
- encodings MAY choose to detect those encodings automatically.
- Automatic encoding detection is particularly important for
- Primary Rate Interfaces, to avoid extensive pre-configuration.
- Only simple encodings are currently distinguished.
-
- The only reliable method of detection available is to switch
- modes between the supported encodings. Transmission of the LCP
- Configure-Request SHOULD be tried twice for each mode before
- switching in rotation. This ensures that sufficient time is
- available for a response to arrive from the peer.
-
- Max-Configure MUST be set such that the cumulative attempts
- result in no more than 59 seconds of time before disconnect.
- It is preferable that the usual limit of 30 seconds be
- observed.
-
- Prior Configuration
-
- By prior configuration, PPP MAY also be used with other
- encodings. Because of difficulty distinguishing them, it is
- not recommended that these encodings be automatically detected.
-
- Terminal adapters conforming to V.120 [6] can be used as a
- simple interface to workstations. Asynchronous HDLC framing
- [2] is accepted at the R reference point. The terminal adapter
- provides async-sync conversion. Multiple B-channels can be
- used in parallel. Unfortunately, V.120 has a framing mode of
- its own for rate adaptation, which is difficult to distinguish
- from Frame Relay, and which can confuse in-band frame
- detection. V.120 is not interoperable with bit-synchronous
- links, since V.120 does not provide octet-stuffing to bit-
- stuffing conversion. Therefore, V.120 is deprecated in favor
- of more modern standards, such as "PPP in Frame Relay" [4].
-
- The "Bandwidth On Demand Interoperability Group" has defined a
- proposal called BONDING. Multiple B-channels can be used in
- parallel. BONDING has an initialization period of its own,
- which might conflict with the simple detection technique
- described above, and requires extensive individual
- configuration in some current implementations when multiple B-
- channels are involved. It is recommended that the PPP
-
-
-
- Simpson expires in six months [Page 3]
- DRAFT PPP over ISDN October 1993
-
-
- multilink procedure [5] be used instead of BONDING.
-
-
- 3. Framing
-
- For B-channels, in the absence of prior configuration, the
- implementation MUST first use bit-synchronous HDLC [2], as opposed to
- other framings, for initial link establishment. This assumes that
- circuit-switched communications are generally [host | router] to
- [host | router].
-
- By prior configuration, octet-synchronous HDLC [2] is recommended
- where the network termination equipment interfaces directly to the T
- reference point, and octet boundaries are available at the time of
- framing. Such equipment is likely to be highly integrated, and the
- elimination of bit-synchronous hardware can reduce the part count,
- resulting in lower cost interfaces and simpler configuration.
- Octet-synchronous HDLC MUST be used with NRZ bit encoding.
-
- For D-channels, by default no data service is expected. By prior
- configuration, "PPP in X.25" [3] or "PPP in Frame Relay" [4] framing
- MAY be used.
-
- Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally
- distinguishable, multiple methods of framing SHOULD NOT be used
- concurrently on the same ISDN channel. There is no requirement that
- PPP recognize alternative framing techniques, or switch between
- framing techniques without specific configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 4]
- DRAFT PPP over ISDN October 1993
-
-
- 4. Out-of-Band signaling
-
- Experience has shown that the LLC Information Element is not reliably
- transmitted end to end. The deployment of compatible switches is too
- limited, and the subscription policies of the providers are too
- diverse. Therefore, transmission of the LLC-IE SHOULD NOT be relied
- upon for framing or encoding determination.
-
- No LLC-IE values which pertain to PPP have been assigned. Any other
- values which are received are not valid for PPP links, and can be
- ignored for PPP service.
-
- As an alternative administrative measure, multiple directory numbers
- can point to the same physical access facility, by binding particular
- services to each directory number. The called party identifier has
- proven to be reliably provided by the local switch.
-
- When a called party identifier is used, or when a future LLC-IE value
- is assigned to PPP and the PPP value is received, if the LCP has not
- had the administrative Open event, the call MUST be rejected.
- Receivers MUST NOT accept an incoming call, only to close the circuit
- or ignore packets from the circuit.
-
-
- 5. Configuration Details
-
- The LCP recommended sync configuration options apply to ISDN links.
-
- The standard LCP sync configuration defaults apply to ISDN links.
-
- The typical network feeding the link is likely to have a MRU of
- either 1500, or 2048 or greater. To avoid fragmentation, the
- Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
- exceed 1500, unless a peer MRU of 2048 or greater is specifically
- negotiated.
-
- Instead of a constant value for the Restart timer, the exponential
- backoff method is recommended. The Restart Timer SHOULD be 250
- milliseconds for the initial value, and 3 seconds for the final
- value.
-
- Implementations that include persistent dialing features, such as
- "demand dialing" or "redialing", SHOULD use mechanisms to limit their
- persistence. Examples of such mechanisms include exponential
- backoff, and discarding packet queues after failure to complete link
- establishment. In some implementations, discarding the transmit
- queue can temporarily remove the stimulus to retry the connection.
-
-
-
-
- Simpson expires in six months [Page 5]
- DRAFT PPP over ISDN October 1993
-
-
- Security Considerations
-
- Security issues are not discussed in this memo.
-
-
- References
-
- [1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
- progress.
-
- [2] Simpson, W.A., "PPP in HDLC Framing", work in progress.
-
- [3] Simpson, W.A., "PPP in X.25", work in progress.
-
- [4] Simpson, W.A., "PPP in Frame Relay", work in progress.
-
- [5] Sklower, K., "PPP MultiLink Procedure", work in progress.
-
- [6] CCITT, "Recommendation V.120: Data Communications over the
- Telephone Network", Blue Book, ITU 1988
-
- [7] Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan,
- 1992.
-
-
- Acknowledgments
-
- This design was inspired by the paper "Parameter Negotiation for the
- Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
- University of California, Berkeley, 1992, unpublished.
-
- Other details were gleaned from "Determination of Encapsulation of
- Multi-protocol Datagrams in Circuit-switched Environments", Keith
- Sklower, University of California, Berkeley, IETF IPLPDN WG draft,
- July 1993. That paper credits previous work "A Subnetwork Control
- Protocol for ISDN Circuit-Switching", Leifer, D., Sheldon, S. and
- Gorsline, B.; IETF IPLPDN WG draft, March 1991; and "A Negotiation
- Protocol for Multiple Link-Protocol over ISDN Circuit-Switching",
- Muramaki, K. and Sugawara, T.; IETF IPLPDN WG draft, May 1992.
-
- Thanks to Oliver Korfmacher (NetCS) for European considerations, Dory
- Leifer (University of Michigan) for technical details and called
- party signalling, and Vernon Schryver (Silicon Graphics) regarding
- handling of link misconfiguration and timeouts.
-
- Special thanks to Morning Star Technologies for providing computing
- resources and network access support for writing this specification.
-
-
-
-
- Simpson expires in six months [Page 6]
- DRAFT PPP over ISDN October 1993
-
-
- Chair's Address
-
- The working group can be contacted via the current chair:
-
- Fred Baker
- Advanced Computer Communications
- 315 Bollay Drive
- Santa Barbara, California 93117
-
- EMail: fbaker@acc.com
-
-
- Author's Address
-
- Questions about this memo can also be directed to:
-
- William Allen Simpson
- Daydreamer
- Computer Systems Consulting Services
- 1384 Fontaine
- Madison Heights, Michigan 48071
-
- EMail: Bill.Simpson@um.cc.umich.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 7]
- DRAFT PPP over ISDN October 1993
-
-
- Table of Contents
-
-
- 1. Introduction .......................................... 1
-
- 2. Physical Layer Requirements ........................... 2
-
- 3. Framing ............................................... 4
-
- 4. Out-of-Band signaling ................................. 5
-
- 5. Configuration Details ................................. 5
-
- SECURITY CONSIDERATIONS ...................................... 6
-
- REFERENCES ................................................... 6
-
- ACKNOWLEDGEMENTS ............................................. 6
-
- CHAIR'S ADDRESS .............................................. 7
-
- AUTHOR'S ADDRESS ............................................. 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Bill.Simpson@um.cc.umich.edu
-